Use of Patterns in Formal Development: Systematic Transition from Problems to Architectural Designs

We present a pattern-based software lifecycle and a method that supports the systematic execution of that lifecycle. First, problem frames are used to develop a formal specification of the problem to be solved. In a second phase, architectural styles are used to construct an architectural specification of the software system to be developed. That specification forms the basis for fine-grained design and implementation. 1 Elaborating the software development process Experience has shown that problems and bugs in software systems take their source mainly in the early phases of the software development process1. Hence, a software development lifecycle that derives the design of the software directly from the requirements and then passes on to the implementation cannot be regarded as satisfactory. The step between requirements and design is too large. An additional phase should be introduced between the requirements and the design. One idea that has been accepted for some time now is that some kind of specification should be set up on the basis of the requirements, so that the requirements are transformed into documents useful for developers. Specifications lead to a deeper understanding of the problems to be solved, and they can be used to support other development activities (e.g. coding, testing, maintenance). However, producing appropriate specifications often turns out to be difficult for practitioners. For instance, finding an appropriate starting point for the formal specification process is a very common problem. M. Jackson [Jac95,Jac01] proposes the use of problem frames for presenting and understanding software development problems. A problem frame is a characterization of a class of problems in terms of their main components and the connections between these components. A set of typical solution methods is associated to each problem frame. The basic idea is that once an appropriate problem frame for a given problem is found, we also have good proposals for constructing a solution to that problem. We think this idea 1 See for example http://www.standishgroup.com/sample research Specification choice of architecture Requirements Design Code choice of problem frame Fig. 1. Lifecycle using problem frames and architectures Requirements Design Spec Code Implementation Spec. Implementation Choices Architectural Choices Design Choices Specification Description Structured Requirements Spec. Architecture Choice of Problem Frame Choice of Arch. Style Fig. 2. Complete lifecycle using problem frames and architectural styles is useful, but it provides only a coarse structure of the problem. Hence, problem frames should be supplemented by means that allow for a finer structuring. Architectural styles [SG96,BCK98] are a means to structure a software system, i.e. to choose its architecture. Since architectural styles are used to construct designs, they should not be used right at the beginning of the development process, but only after the problem has been fully understood and specified. Figure 1 shows how to bridge the gap between the requirements and the design of a software system. It is possible to elaborate the software development lifecyle further, as suggested in Figure 2. Here, several phases are introduced between the requirements and the design of a software system. Problem frames and architectural styles are both forms of patterns. While problem frames are concerned with problems, architectural styles are concerned with solutions. Hence, with Figures 1 and 2, we propose a pattern-based software lifecycle. Patterns should be used systematically and on different levels of abstraction. In the following, we show how the steps from an informal requirements description to an architectural specification shown in Figure 2 can be carried out in a systematic way. This work further elaborates the approach by Choppy and Reggio [CR00], where problem frames are used to structure formal specifications. We first discuss how patterns can be used on different abstraction levels and in different phases of the software development process in Section 2. Section 3 presents a method to carry out pattern based formal development in a systematic way. The application of that method is illustrated by the case study of a robot simulation in Section 4. In Section 5, we summarize our work and also discuss related work that aims at methodological support for developing formal specifications. 2 Patterns for different software development activities Patterns are a means to reuse software development knowledge on different levels of abstraction. Patterns classify sets of software development problems or solutions that share the same structure. Patterns have been introduced on the level of detailed object oriented design [GHJV95]. Today, patterns are defined for different activities. Problem Frames [Jac01] are patterns Control CD!C2 CM!C1 domain Controlled C C3 machine behaviour Required